Skip to content

build(deps): bump github.com/redis/go-redis/v9 from 9.20.1 to 9.21.0#154

Closed
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/go_modules/github.com/redis/go-redis/v9-9.21.0
Closed

build(deps): bump github.com/redis/go-redis/v9 from 9.20.1 to 9.21.0#154
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/go_modules/github.com/redis/go-redis/v9-9.21.0

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Jun 22, 2026

Copy link
Copy Markdown
Contributor

Bumps github.com/redis/go-redis/v9 from 9.20.1 to 9.21.0.

Release notes

Sourced from github.com/redis/go-redis/v9's releases.

9.21.0

This is a minor release adding new features and bug fixes. There are no breaking changes; upgrading from 9.20.x is a drop-in replacement.

🚀 Highlights

Zero-copy GetToBuffer / SetFromBuffer

Two new StringCmdable methods let callers read and write Redis string values directly into and from pre-allocated byte buffers, eliminating the per-call payload allocation that Get/Set incur:

GetToBuffer(ctx, key, buf) *ZeroCopyStringCmd   // reads into buf; ZeroCopyStringCmd { Val() int; Bytes() []byte; Result() (int, error) }
SetFromBuffer(ctx, key, buf) *StatusCmd

GetToBuffer decodes the bulk reply straight into the caller-owned buf (no intermediate allocation); a buffer that is too small returns an error after draining the payload, so the connection stays aligned for the next reply. SetFromBuffer is provided for API symmetry — it dispatches to the same []byte writer path as Set(ctx, key, buf, 0) and produces byte-identical output on the wire. Available on *Client, *ClusterClient, *Ring, *Conn and Pipeliner.

(#3834) by @​ndyakov

Explicit LIMIT 0 for stream trimming

Redis treats XTRIM/XADD approximate-trim (~) LIMIT 0 as "disable the trimming effort cap entirely", which differs from omitting LIMIT (the implicit 100 * stream-node-max-entries default). The command builders previously only emitted LIMIT when limit > 0, so callers could never send an explicit LIMIT 0. Following the KeepTTL = -1 precedent, the new XTrimLimitDisabled = -1 sentinel now emits an explicit LIMIT 0; limit == 0 keeps the historical no-LIMIT behavior, so existing callers produce byte-identical commands.

(#3848) by @​TheRealMal

✨ New Features

  • Zero-copy buffer string commands: new GetToBuffer / SetFromBuffer on StringCmdable and the ZeroCopyStringCmd result type, reading/writing string values into caller-owned buffers without per-call payload allocation (#3834) by @​ndyakov
  • XTrimLimitDisabled sentinel: XTRIM/XADD approximate trimming can now send an explicit LIMIT 0 to disable the trim effort cap, via the new XTrimLimitDisabled = -1 sentinel (#3848) by @​TheRealMal
  • PubSub health-check timeouts: channel.initHealthCheck now bounds the Ping it issues with a fresh per-check timeout context (the exported pingTimeout / reconnectTimeout) instead of context.TODO(), so a stuck health-check Ping can no longer block indefinitely (#3819) by @​abdellani
  • Skip redundant UNWATCH in Tx.Close: a transaction now tracks whether a WATCH is still active (watchArmed) and only issues UNWATCH on Close when it is, removing an extra round trip on the common WATCH/.../EXEC and no-key Watch paths while never returning a connection to the pool with an active watch (#3854) by @​fcostaoliveira

🐛 Bug Fixes

  • maintnotifications ModeAuto fail-open: ModeAuto now stays fail-open when the server does not support maintenance notifications — connections are retired and tracking is guarded during downgrade so the client keeps working instead of erroring (#3853) by @​terrorobe

👥 Contributors

We'd like to thank all the contributors who worked on this release!

@​abdellani, @​fcostaoliveira, @​ndyakov, @​terrorobe, @​TheRealMal

Changelog

Sourced from github.com/redis/go-redis/v9's changelog.

9.21.0 (2026-06-18)

This is a minor release adding new features and bug fixes. There are no breaking changes; upgrading from 9.20.x is a drop-in replacement.

🚀 Highlights

Zero-copy GetToBuffer / SetFromBuffer

Two new StringCmdable methods let callers read and write Redis string values directly into and from pre-allocated byte buffers, eliminating the per-call payload allocation that Get/Set incur:

GetToBuffer(ctx, key, buf) *ZeroCopyStringCmd   // reads into buf; ZeroCopyStringCmd { Val() int; Bytes() []byte; Result() (int, error) }
SetFromBuffer(ctx, key, buf) *StatusCmd

GetToBuffer decodes the bulk reply straight into the caller-owned buf (no intermediate allocation); a buffer that is too small returns an error after draining the payload, so the connection stays aligned for the next reply. SetFromBuffer is provided for API symmetry — it dispatches to the same []byte writer path as Set(ctx, key, buf, 0) and produces byte-identical output on the wire. Available on *Client, *ClusterClient, *Ring, *Conn and Pipeliner.

(#3834) by @​ndyakov

Explicit LIMIT 0 for stream trimming

Redis treats XTRIM/XADD approximate-trim (~) LIMIT 0 as "disable the trimming effort cap entirely", which differs from omitting LIMIT (the implicit 100 * stream-node-max-entries default). The command builders previously only emitted LIMIT when limit > 0, so callers could never send an explicit LIMIT 0. Following the KeepTTL = -1 precedent, the new XTrimLimitDisabled = -1 sentinel now emits an explicit LIMIT 0; limit == 0 keeps the historical no-LIMIT behavior, so existing callers produce byte-identical commands.

(#3848) by @​TheRealMal

✨ New Features

  • Zero-copy buffer string commands: new GetToBuffer / SetFromBuffer on StringCmdable and the ZeroCopyStringCmd result type, reading/writing string values into caller-owned buffers without per-call payload allocation (#3834) by @​ndyakov
  • XTrimLimitDisabled sentinel: XTRIM/XADD approximate trimming can now send an explicit LIMIT 0 to disable the trim effort cap, via the new XTrimLimitDisabled = -1 sentinel (#3848) by @​TheRealMal
  • PubSub health-check timeouts: channel.initHealthCheck now bounds the Ping it issues with a fresh per-check timeout context (the exported pingTimeout / reconnectTimeout) instead of context.TODO(), so a stuck health-check Ping can no longer block indefinitely (#3819) by @​abdellani
  • Skip redundant UNWATCH in Tx.Close: a transaction now tracks whether a WATCH is still active (watchArmed) and only issues UNWATCH on Close when it is, removing an extra round trip on the common WATCH/.../EXEC and no-key Watch paths while never returning a connection to the pool with an active watch (#3854) by @​fcostaoliveira

🐛 Bug Fixes

  • maintnotifications ModeAuto fail-open: ModeAuto now stays fail-open when the server does not support maintenance notifications — connections are retired and tracking is guarded during downgrade so the client keeps working instead of erroring (#3853) by @​terrorobe

👥 Contributors

We'd like to thank all the contributors who worked on this release!

@​abdellani, @​fcostaoliveira, @​ndyakov, @​terrorobe, @​TheRealMal


Full Changelog: redis/go-redis@v9.20.1...v9.21.0

Commits
  • 1551837 chore(release): 9.21.0 (#3857)
  • 1cfa927 fix(maintnotifications): keep ModeAuto fail-open (#3853)
  • 1f0ea0e feat(pubsub): introduce timeouts for Ping on channel.initHealthCheck (#3819)
  • 5484b0b feat(tx): skip redundant UNWATCH in Tx.Close when no WATCH is active (#3854)
  • bf57a51 chore(deps): bump rojopolis/spellcheck-github-actions (#3852)
  • 641294c feat(streams): support explicit LIMIT 0 in XTRIM/XADD trimming via XTrimLimit...
  • 74d9bb0 feat(command): add zero-copy GetToBuffer and SetFromBuffer (#3834)
  • See full diff in compare view

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Bumps [github.com/redis/go-redis/v9](https://github.com/redis/go-redis) from 9.20.1 to 9.21.0.
- [Release notes](https://github.com/redis/go-redis/releases)
- [Changelog](https://github.com/redis/go-redis/blob/master/RELEASE-NOTES.md)
- [Commits](redis/go-redis@v9.20.1...v9.21.0)

---
updated-dependencies:
- dependency-name: github.com/redis/go-redis/v9
  dependency-version: 9.21.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file go Pull requests that update go code labels Jun 22, 2026
@dependabot dependabot Bot requested a review from hyp3rd as a code owner June 22, 2026 21:24
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file go Pull requests that update go code labels Jun 22, 2026
@dependabot @github

dependabot Bot commented on behalf of github Jun 23, 2026

Copy link
Copy Markdown
Contributor Author

Looks like github.com/redis/go-redis/v9 is up-to-date now, so this is no longer needed.

@dependabot dependabot Bot closed this Jun 23, 2026
@dependabot dependabot Bot deleted the dependabot/go_modules/github.com/redis/go-redis/v9-9.21.0 branch June 23, 2026 16:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file go Pull requests that update go code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants